<?xml version="1.0" encoding="UTF-8"?>
<html>
    <head>
        <link type="text/css" rel="stylesheet" href="./css/template.css" />
        <link type="text/css" rel="stylesheet" href="./css/SyntaxHighlighter.css" />
        <meta http-equiv="Content-Type" content="text/html; charset=UTF-8" />
        <title>Java pour le Mobiles - J2ME</title>
        <keywords>J2ME,presentation,CLDC,MIDP,midlet,Java,Java ME,java,pour,le,mobiles,j2me,articles,1,1,certification,sun,java,solaris,articles,essentiels,tips,astuces,codes,exemple,tutorial,developpement,jsp,servlet,jdbc,jdo,j2se,j2ee,laboratoire</keywords>
        <script language="javascript" src="./js/shInit.js" />
        <script language="javascript" src="./js/shCore.js" />
        <script language="javascript" src="./js/shBrushCpp.js" />
        <script language="javascript" src="./js/shBrushCSharp.js" />
        <script language="javascript" src="./js/shBrushCss.js" />
        <script language="javascript" src="./js/shBrushDelphi.js" />
        <script language="javascript" src="./js/shBrushJava.js" />
        <script language="javascript" src="./js/shBrushJScript.js" />
        <script language="javascript" src="./js/shBrushPhp.js" />
        <script language="javascript" src="./js/shBrushPython.js" />
        <script language="javascript" src="./js/shBrushRuby.js" />
        <script language="javascript" src="./js/shBrushSql.js" />
        <script language="javascript" src="./js/shBrushVb.js" />
        <script language="javascript" src="./js/shBrushXml.js" />
        <author>Serhiy KVITKA</author>
    </head>
    <body>
        <div class="chapter">
            <p>﻿</p>
        </div>
        <!-- debut du contenu -->
        <div class="chapter">
            <h2>Java pour les Mobiles - J2ME</h2>
        </div>
        <div class="chapter">
            <h2>Introduction</h2>
            <p>
                A l'origine la plateforme Java 2 Micro Edition (J2ME) a été créée pour développer des applications sur des équipements à ressources limitées en autonomie, en mémoire et en
				processeur tels que, les téléphones portables, les smart cards, les palms, les organizers et les mini-ordinateurs.
                <br />
                La plateforme J2ME permet construire de un Java Runtime Environment (JRE) complet, qui s'adapte aux besoins des équipements à ressources limitées.
                <br />
                J2ME introduit trois grandes notions : la configuration, les profiles et les Midlet.
                <br />
                Vous pouvez trouver les informations détaillées sur le site officiel de Sun Microsystems :
                <br />
            </p>
            <p>
                <i>
                    <span>
                        <a href="http://java.sun.com/j2me/" target="_blank">http://java.sun.com/j2me/</a>
                    </span>
                </i>
            </p>
            <br />
        </div>
        <div class="chapter">
            <h2>1.La configuration</h2>
            <p>
                Elle détermine le milieu d'exécution de J2ME. Elle inclut une machine virtuelle limitée par rapport à la VM standard  et d'un certain nombre de classe principale empruntées à J2SE.
				Actuellement, il y a deux configurations déterminées :
                <br />
            </p>
            <ul>
                <li>Connected Limited Device Configuration (CLDC)</li>
                <li>Connected Device Configuration (CDC)</li>
            </ul>
            <p>
                La CLDC est orientée vers les mini mobiles équipés de processeurs 16/32 bits dont la mémoire est de 128 KB minimum.
                <br />
                Le point avantageux de J2ME CLDC consiste en une machine virtuelle K Virtuel Machine (KMV), mise au point spécialement pour les interfaces réseaux à mémoire et ressources limitées.
				La CDC est orientée vers les équipements de plus grande capacité tel que : smart communicateurs, pagers, PDA, Sony PlayStation, XBox, etc).
				La CDC met en marche la machine virtuelle C Virtuel Machine (CVM).
                <br />
                La CDC est composée de toutes les classes de CLDC plus d'autre classes de J2SE.
            </p>
            <!--La différence principale entre CDC et CLDC est ce que CDC VM maintient toutes les possibilités de J2SE VM y compris native programming interfaces.<br> -->
        </div>
        <div class="chapter">
            <h2>2. Profile</h2>
            <p>Le profile élargit la configuration en ajoutant des classes spécifiques au nombre de classes générales, définies dans leur configuration.
				Autrement dit, le profile assure la fonctionnalité indispensable qui manque dans la configuration générale. Cela peut être une interface d'utilisateur, un mécanisme de sauvegarde, etc.
				A part le profile MIDP ( Mobile Information Device Profile) il en existe d'autres.</p>
            <div class="subChapter">
                <h3>2.1. Foundation Profile</h3>
                <p>" Foundation Profile " sert à ajouter un certain nombre de classes de J2SE à CDC, mais il ne s'agit pas d'introduire une interface d'utilisateur.
					A partir de ce profile, on construit d'autres profiles.</p>
            </div>
            <div class="subChapter">
                <h3>2.2. Personal Basic Profile</h3>
                <p>" Personal Basic Profile " sert à assurer Java API pour les mobiles qui demandent l'accès au réseau et une présentation graphique.
					Ce profile est très utile pour la télévision interactive car il contient également une API pour le maintien de Multimedia Home Platform (JSR 129).</p>
            </div>
            <div class="subChapter">
                <h3>2.3. Personal Profile</h3>
                " Personal Profile " sert à assurer le support de l'API JAVA pour les mobiles qui demandent un accès au réseau solide fondé sur "Personal Basic Profile " et " Foundation Profile " (JSR62).
                <br />
                <p align="center">
                    <span style="font-size: 12.0pt; font-family: Times New Roman">
                        <img border="0" src="./images/21.bmp" />
                        <br />
                    </span>
                    <br />
                    <i>Architecture J2ME. * - ou développement.</i>
                </p>
                <br />
            </div>
        </div>
        <div class="chapter">
            <h2>3. CLDC (Configuration des mobiles de communication à ressources limitées)</h2>
            <p>
                CLDC est le résultat du travail de Java Community Process (JCP), un groupe d'expert JSR-30, qui représente les compagnies suivantes :
                <br />
            </p>
            <ul>
                <li>Sun Microsystems</li>
                <li>America Online</li>
                <li>Bull</li>
                <li>Ericsson</li>
                <li>Fujitsu</li>
                <li>Matsushita</li>
                <li>Mitsubishi</li>
                <li>Motorola</li>
                <li>Nokia</li>
                <li>NTT DoCoMo</li>
                <li>Oracle</li>
                <li>Palm Computing</li>
                <li>RIM</li>
                <li>Samsung</li>
                <li>Sharp</li>
                <li>Siemens</li>
                <li>Sony</li>
                <li>Symbian</li>
            </ul>
            <p>
                Le but de cette technologie est de déterminer un standard d'utilisation de Java sur les mobiles à ressources limitées :
                <br />
            </p>
            <ul>
                <li>160-500 Kb de mémoire accessible à la plateforme Java</li>
                <li>Processeur à 16-32 bits</li>
                <li>Faible consommation d'énergie</li>
                <li>connexion aux réseaux de 9600 bps ou moins</li>
            </ul>
            <p>
                Ci-dessous, sont présentés des aspects qui tombent sous la " juridiction " de CLDC :
                <br />
            </p>
            <ul>
                <li>Java langue et la machine virtuelle KVM</li>
                <li>Bibliothèques de Java principales (java.lang.*, java.util.*)</li>
                <li>Modèle de sécurité</li>
                <li>Opération I/O</li>
                <li>Support du réseau</li>
                <li>Internalisation</li>
            </ul>
            <p>
                Les aspects cités ci-dessous sont déterminés par des profiles :
                <br />
            </p>
            <ul>
                <li>Interface d'utilisateur</li>
                <li>Traitement des événements</li>
                <li>Période de validité des applications</li>
                <li>Liaison entre un utilisateur et une application</li>
                <ul />
            </ul>
        </div>
        <div class="chapter">
            <h2>4. Le langage Java et la machine virtuelle KVM</h2>
            <p>
                L'objectif pour JVM, maintenant CLDC, c'est d'être compatible avec Java Language Specification autant que possible. Excepté les différences citées
				ci-dessous, JVM peut être considéré compatible avec Java Language Specification.
                <br />
                Il n'y a pas de support du type floating point, dans les mobiles à ressources limitées. Cela n'existe pas parce que le support floating point au niveau de
				la programmation comporte  des frais supplémentaires. Il n'y a pas de méthode finalize(), pas de weak references non plus. Cette exigence est liée à la nécessité de simplifier le mécanisme de nettoyage.
				CLDC maintient le mécanisme d'exception.
                <br />
                Pourtant, sa capacité est limitée pour deux raisons. Le rétablissement après une exception est toujours spécifique pour chaque mobile (certains d'entre eux redémarrent tous seuls après avoir détecté les fautes).
				L'application ne peut pas s'occuper de ces exceptions. La réalisation complète du mécanisme est trop chère pour les micro mobiles.
            </p>
            <div class="subChapter">
                <h3>4.1. KVM</h3>
                <p>
                    La KVM ne supporte pas de floating point. Il n'existe pas dans les mobiles à ressources limitées pour la raison qu'il serait trop cher de le maintenir au
					niveau de programmation. Dans JVM maintenant CLDC il n'y a pas non plus de byte code liés aux types float et double.
                    <br />
                    La KVM ne réalise pas Java Native Interface (JNI). Le support JNI a été rejeté pour plusieurs raisons. Le modèle sécurité de CLDC interdit l'utilisation des appels native.
					La réalisation complète de JNI a été considérée trop chère pour les mobiles à ressources limitées. La KVM ne permet pas de créer son class loader. Cette interdiction est imposée par la modèle de sécurité.
					La KVM ne supporte pas le mécanisme de Reflection. Les applications de Java ne peuvent pas inspecter les classes, les objets, les méthodes, les champs,
					les fils exécutés par la machine virtuelle. Par conséquent, les technologies comme JVMI (Debugging Interface), JVMPI (Profiler Interface) et d'autres
					technologies de J2SE, basées sur le mécanisme de Reflection sont absentes dans CLDC.
                    <br />
                    La KVM  réalise le multiplex, mais elle ne supporte pas les Thread groups et les daemon threads. Les opérations comme le lancement et l'arrêt peuvent être
					appliquées uniquement dans un seul Thread. Il ne peut pas utiliser la méthode finalize(), ainsi que weak réferences car cette condition est indispensable  pour que le mécanisme de nettoyage
					soit moins compliqué. Le mécanisme error handling est moins développé par rapport à celui de J2SE.
                </p>
            </div>
        </div>
        <div class="chapter">
            <h2>5. Les bibliothèques de CLDC</h2>
            <p>
                On distingue deux catégories de bibliothèques de CLDC.
                <br />
                Dans la première catégorie sont incluses les classes de J2SE. Dans la deuxième, les classe introduites par CLDC.
                <br />
                Les classes  de la première catégorie se situent dans les paquets java.lang.*, java.util.* et java.io.*.
				Ces classes sont dérivées de Java 2 Standard Edition version 1.3. Elles sont identiques à celles de J2SE.
				La sémantique des classes et de leurs méthodes ne changera pas.
				Les méthodes public () ou protected (), qui ne sont pas accessibles à J2SE, ne s'y ajouteront pas.
                <br />
            </p>
            <div class="subChapter">
                <h3>5.1. Les classes système</h3>
                Les classes données sont liées intérieurement à la machine virtuelle.
				Certaines applications de Java demandent l'assistance des classes données.
				Exemple : J2SE Java compiler (javac), en générant le code, demande la présence de certaines fonctions de String et StringBuffer classes.
                <br />
                <p align="center">
                    <span style="FONT-SIZE: 12pt; FONT-FAMILY: Times New Roman">
                        <img src="./images/51.bmp" border="0" />
                        <br />
                    </span>
                </p>
                Les classes représentant des types.
                <br />
                Chacune de ces classes se représente une sous multitude des classes correspondantes de J2SE.
                <br />
                <p align="center">
                    <span style="FONT-SIZE: 12pt; FONT-FAMILY: Times New Roman">
                        <img src="./images/52.bmp" border="0" />
                        <br />
                    </span>
                </p>
                Collection classes.
                <br />
                <p align="center">
                    <span style="FONT-SIZE: 12pt; FONT-FAMILY: Times New Roman">
                        <img style="WIDTH: 477px; HEIGHT: 93px" height="93" src="./images/53.bmp" width="473" border="0" />
                        <br />
                    </span>
                </p>
                I/O classes.
                <br />
                <p align="center">
                    <span style="FONT-SIZE: 12pt; FONT-FAMILY: Times New Roman">
                        <img src="./images/54.bmp" border="0" />
                        <br />
                    </span>
                </p>
                Les classes Reader, Writer, InputStreamReader et InputStreamWriter permettent d'assurer le support de l'internalisation.
                <br />
                Le mécanisme de leur travail est le même que celui de J2SE. Ses deux dernières classes ont les mêmes constructeurs que dans J2SE.
                <br />
                <p align="center">
                    <span style="FONT-SIZE: 12pt; FONT-FAMILY: Times New Roman">
                        <img src="./images/55.bmp" border="0" />
                        <br />
                    </span>
                </p>
                Dans les cas où le paramètre String est présent, il faut utiliser character encoding, dont le nom est inscrit dans une variable de microedition.encoding.
				Si le convertisseur n'est pas accessible, UnsupportedEncodingException apparaît.
                <br />
                Il faut bien noter que CLDC ne supporte pas la localisation. Donc, ce fait prouve que toutes les décisions liées à l'action de formatage de la date,
				de l'heure, etc. se trouvent hors de l'examen de CLDC.
                <br />
            </div>
            <div class="subChapter">
                <h3>5.2.  Le calendrier et l'heure</h3>
                CLDC inclut une certaine multitude des classes standard de J2SE :
				java.util.Calender, java.util.Date et java.util.TimeZone. Par défaut, il maintient le même fuseau horaire.
                <br />
                <p align="center">
                    <span style="FONT-SIZE: 12pt; FONT-FAMILY: Times New Roman">
                        <img src="./images/56.bmp" border="0" />
                        <br />
                    </span>
                </p>
            </div>
            <div class="subChapter">
                <h3>5.3. Les classes secondaires</h3>
                Java.util.Random est une classe qui contient le générateur de nombres fortuits.
				Java.lang.Math dispose des méthodes comme abs, max et min pour les types int et long.
                <br />
            </div>
            <div class="subChapter">
                <h3>5.4. Exception &amp; Error</h3>
                <p align="center">
                    <span style="FONT-SIZE: 12pt; FONT-FAMILY: Times New Roman">
                        <img src="./images/57.bmp" border="0" />
                        <br />
                    </span>
                </p>
            </div>
        </div>
        <div class="chapter">
            <h2>6. Propriété</h2>
            Dans CLDC il n'y a pas de classe java.util.Properties. Cependant, une propriété peut être accessible en appliquant la méthode statique
			System.getProperty (String key). Le nombre minimal de propriété, donné par CLDC est le suivant :
            <br />
            <ul>
                <li>microedition.encoding</li>
                <li>microedition.platform</li>
                <li>microedition.configuration</li>
                <li>microedition.profiles</li>
                <ul>
                    <br />
                    Les classes qui appartiennent à la  deuxième catégorie se trouvent dans les paquets Java.microedition.*.
                    <br />
                    Le paquet javax.microedition.io introduit un nouveau mécanisme de support de réseau.
                    <br />
                </ul>
            </ul>
        </div>
        <div class="chapter">
            <h2>7. CLDC Connection Framework</h2>
            Java.io.* et java.net.* sont des paquets de J2SE qui ne conviennent pas pour les mobiles à cause de leurs ressources limités. Voilà pourquoi,
			il a été développé un nouveau paquet java.microedition.io. Ce paquet ne contient qu'une seule classe : Connector, 8 interfaces et ConectionNotFoundException.
            <br />
            La classe Connector - c'est le " coeur " de Connection Framework. Il a une série de méthodes statiques pour la réception de l'objet de Connection. Si l'opération est réussie, la méthode renvoie l'objet qui
			réalise la connexion à l'interface, ou bien, IOException apparaît.
            <br />
            <p align="center">
                <span style="font-size: 12.0pt; font-family: Times New Roman">
                    <img border="0" src="./images/71.bmp" />
                    <br />
                </span>
                <br />
                <i>La hiérarchie des interfaces</i>
            </p>
            <br />
            L'objet réalisant la connexion à l'interface peut être reçu grâce à la classe Connector comme dit ci-dessus. L'interface Connection a la seule méthode close() qui ferme la connexion au réseau.
            <br />
            InputConnection, c'est l'interface qui permet de lire les données. Les méthodes openInputStream et openDataInputStream retournent les données pour la lecture
            <br />
            OutputConnection, c'est l'interface qui permet d'enregistrer les données. Les méthodes openOutputStream et openDataOutputStream retournent les données pour l'enregistrement
            <br />
            StreamConnection, c'est l'interface qui réunie en soi InputConnection et OutputConnection.
            <br />
            ContentConnection est la sous interface de StreamConnection.
            <br />
            SteamConnectionNotified attend que la connexion soit établie. La méthode acceptAndOpen() renvoie l'objet StreamConnection.
            <br />
            DatagrameConnection interface détermine la connexion datagramme.
            <br />
            ConnectionNotFoundException s'apparaître quand la connexion ne peut pas être établie
            <br />
        </div>
        <div class="chapter">
            <h2>8. Connecter</h2>
            Le paramètre String appartenant à la méthode de la classe " open " de se Connecter avec le format suivant : " protocole:adresse:paramètres  "
            <br />
            <br />
            Exemples du code :
            <br />
            <p align="center">
                <span style="font-size: 12.0pt; font-family: Times New Roman">
                    <img border="0" src="./images/81.bmp" />
                    <br />
                </span>
            </p>
        </div>
        <!-- niveau atteint au 25 01 08 -->
        <div class="chapter">
            <h2>9. Sécurité</h2>
            <p>
                L'un des plus grands avantages de Java, c'est le chargement dynamique des applications par le réseau chez le client en utilisant un mécanisme
				solide de sécurité. La réalisation de ce mécanisme en J2SE dépasse les ressources de mémoire de JVM qui supporte CLDC. Pour cette dernière,
				il a été développé un autre mécanisme qui peut être divisé en deux niveaux, celui de la machine virtuelle et celui de l'application.
                <br />
                Le niveau de machine virtuelle sous-entend que l'application démarrée dans la machine virtuelle ne doit avoir aucune possibilité d'endommager
				le mobile. Cette condition assurée par Java classfile Verifier doit garantir que le byte code démarré ne contient pas de liens vers les domaines
				non valables de la mémoire. Verifier doit rejeter le chargement de ces classes. Vérifier n'est pas le moyen universel contre tous les problèmes. Sa fonction est justement  de vérifier le byte code
				de façon générale, mais cela ne peut pas garantir que le mobile ne sera pas endommagé par une application démarrée. Dans J2SE, Security
				Manager effectue le contrôle sur  l'application pour qu'elle ne puisse pas sans autorisation s'adresser au système, établir la connexion, etc.
				Mais les  mobiles ne peuvent pas réaliser un contrôle pareil à cause de leurs ressources limités.
				Dans JVM que CLDC supporte, a été réalisé une sandbox security modèle. Là, il est supposé que l'application doit s'effectuer dans un environnement déterminé où elle a accès uniquement
				aux API qui ont été déterminés lors de la configuration, dans les profiles et dans les classes autorisées.
                <br />
                Pour être plus précis, le sandbox model signifie que les fichiers de la classe Java démarrés doivent passer la vérification.
                <br />
                Le chargement des applications peut être effectué avec le code natif de la machine virtuelle et ne peut pas réaliser class loader par
				l'utilisateur. Donc, il est impossible de créer son propre class loader. L'application ne peut pas charger la bibliothèque native. L'application ne peut pas avoir d'accès aux fonctions native qui sont accessibles pour
				la machine virtuelle, ainsi  qu'aux bibliothèques natives qui ne sont pas les bibliothèques de Java maintenues par CLDC, les profiles et classes
				autorisées. La réalisation de CLDC doit assurer l'impossibilité de redémarrage de paquets de système java.*, javax.microedition.*.
				Outre cela, les fichiers peuvent rajouter leurs propres restrictions à celles, mentionnées ci-dessus.
            </p>
        </div>
        <div class="chapter">
            <h2>10. MIDP</h2>
            Mobile Information Device Profile élargit CLDC en y ajoutant trois nouveaux paquets :
            <br />
            <ul>
                <li>javax.microedition.midlet</li>
                <li>javax.microedition.lcdui</li>
                <li>javax.microedition.rms</li>
            </ul>
            <br />
            Il est exigé sous certaines conditions lors de l'installation des MIDlet.
			On ajoute une série de classes aux paquets déjà existants et déterminés dans CLDC.
            <br />
            Au paquet de java.io on ajoute HttpConnection interface.
            <br />
            Au paquet de java.lang on ajoute IllegalStateException (java.lang.IllegalStateException).
            <br />
            On ajoute de la fonctionnalité qui permet aux applications de créer des timers. Dans ce but, on a ajouté aussi les classes
			java.util.Timer et java.util.TimerTask qui viennent de J2SE.
            <br />
            Le composant principal d'interface d'utilisateur MIDP est screen.
            <br />
        </div>
        <!-- A PARTIR DU 11 VERIFIER LE PATH DES IMAGES -->
        <div class="chapter">
            <h2>11. Midlet</h2>
            Mobile Information Device Profile n'a pas de ressemblance avec le modèle Applet introduite en J2SE. MIDP introduit un nouveau modèle, construit à
			la base de CLDC, qui permet à la multitude des applications Java de démarrer concurremment sur KVM et de partager les données.
            <br />
            Voyons, donc, l'examen de MIDP sur l'exemple le plus simple Hello World. Son code est présenté ci-dessous.
            <br />
            <p align="center">
                <span style="font-size: 12.0pt; font-family: Times New Roman">
                    <img border="0" src="data/resources/597/images/111.JPG" />
                    <br />
                </span>
            </p>
            Étudions l'exemple donné en détail :
            <br />
            <br />
            Premièrement, ce qu'on fait, c'est la création de la classe qui réalise une classe abstraite java.microedition.midlet.Midlet. Pour réaliser cette
			classe, il est indispensable de réaliser 3 méthodes abstraites  starApp, pauseApp et destroyApp. Ces 3 méthodes déterminent le cycle de vie du midlet.
            <br />
            Mais tout d'abord, quelques mots sur l'histoire  de la création de l'objet MIDlet. Dans le modèle MIPD, le système éveille dans le public
			constructeur sans arguments pour créer un objet MIDlet. Si vous voulez lui donner des initiales, c'est justement l'endroit où il faut saisir le code.
            <br />
            <br />
            La méthode starApp est appelée par le système pour démarrer ou redémarrer le midlet. Son but est la préparation du midlet au travail, par exemple,
			la répartition des ressources et la création de l'interface d'utilisateur nécessaire. La méthode starApp peut être terminée de deux façons qu'on appelle
			transient et non transient. Transient, ce n'est pas un cas fatal, le midlet peut " dire " au système qu'il a été lancé encore une fois plus tard.
			Pour cela le midlet retourne une MIDletStateChangeException. Non-transient , c'est le cas quand il arrive quelque chose d'extraordinaire qui n'a pas été
			planifié, un problème, par exemple, une Error ou RuntimeException. Dans ce cas, le midlet devra se détruire à l'aide de la méthode destroyApp.
            <br />
            <br />
            Ces 2 situations sont présentées ci-dessous.
            <br />
            <p align="center">
                <span style="font-size: 12.0pt; font-family: Times New Roman">
                    <img border="0" src="data/resources/597/images/112.JPG" />
                    <br />
                </span>
            </p>
            <br />
            La méthode pauseApp est appelée par le système pour suspendre l'activité du midlet. Dans cette situation, le midlet doit s'arrêter et
			rendre disponibles les ressources dont il n'a plus besoin. Ce dernier est très important car les ressources de KVM sont assez limitées. La méthode
			pauseApp, en général, doit fonctionner en même temps que la méthode startApp.
            <br />
            <p align="center">
                <span style="font-size: 12.0pt; font-family: Times New Roman">
                    <img border="0" src="data/resources/597/images/113.JPG" />
                    <br />
                </span>
            </p>
            <br />
            Et la dernière méthode destroyApp s'éveille par le système pour " annoncer " au midlet, qu'il sera détruit et qu'il se prépare à
			la procédure: fermer les ressources et sauvegarder l'information nécessaire.
            <br />
            <p align="center">
                <span style="font-size: 12.0pt; font-family: Times New Roman">
                    <img border="0" src="data/resources/597/images/114.JPG" />
                    <br />
                </span>
            </p>
            <br />
        </div>
        <div class="chapter">
            <h2>12. Cycle de vie d'une Midlet</h2>
            Maintenant, passons à l'étude du cycle de vie du midlet. Quand il est en veille, il peut avoir l'un des 3 états suivants :
            <br />
            <p align="center">
                <span style="font-size: 12.0pt; font-family: Times New Roman">
                    <img border="0" src="data/resources/597/images/121.JPG" />
                    <br />
                </span>
            </p>
            <div class="subChapter">
                <h3>12.1. Paused State</h3>
                Dans  l'état Paused State, le midlet peut demeurer, premièrement, s'il vient d'être créé, et la méthode startApp n'a pas encore été mise
				en circuit/service, et deuxièment, en résultat des appels à pauseApp ou des méthodes notifyPaused. Dès que le midlet aura retrouvé cet état, il
				devra rendre disponibles les ressources dont il n'a plus besoin. Mais il reste toujours " en vie " car il peut toujours recevoir des messages
				asynchrones comme, par exemple, celui du Timer. Cependant, il faut bien noter que le système peut ne pas réaliser cet état. À titre d'exemple
				prenons une situation où le midlet a été démarré, et en même temps le mobile a reçu un appel. Dans ce cas, le mobile peut simplement " tuer "
				la machine virtuelle si ce mobile ne peut pas réalisé l'état Paused.
            </div>
            <div class="subChapter">
                <h3>12.2. Active State</h3>
                Le midlet étant en état Active après la mise en service de la méthode startApp, ou bien, après avoir quitté l'état Paused en résultat de
				l'appel à resumeRequest.
            </div>
            <!-- Niveau atteint aujourd'hui -->
            <div class="subChapter">
                <h3>12.3. Destroyed State</h3>
                L'état de Destroyed State, le midlet se retrouve après l'appel à destroyApp ou notifyDestroyed. Étant dans cet état, le midlet ne peut
				pas passer à un autre état. Le passage d'un état à un autre se produit par le système ainsi que par le midlet lui même.
                <br />
                <br />
                Maintenant, résumons l'information sur six méthodes des classes MIDlet. La septième méthode, getAppProperty, ne concerne pas
				" le cycle de vie " d'une midlet.
                <br />
                La méthode startApp est appellé par le système pour mettre une midlet dans un état Active, ou pour la remettre en service après
				l'état Paused. Il ne faut pas confondre la méthode startApp et la méthode main. La méthode startApp peut être appelé plus d'une fois.
                <br />
                La méthode pauseApp qui peut être appelé par le système dans deux cas de figure. Si le mobile reçoit un appel, ou bien, s'il manque
				de mémoire. Dans ce dernier cas, le midlet doit " libérer " les ressources.
                <br />
                La méthode destroyApp est une voie " normal " de terminer le travail du midlet. Cette méthode a un paramètre boolean (unconditional).
				Ce paramètre montre si l'appel est " inconditionnel ". Autrement dit, si l'appel est égal à fasle et le midlet n'est pas
				prêt à terminer son travail, il peut " demander  la vie " au système, ayant lancé MIDletStateChangeException. Le système, alors, peut
				exécuter cette demande, donc l'état du midlet ne changera pas.
				Dans le cas où le paramètre serait égal à true, le midlet doit " obéir " sans " demander la vie ", et rendre disponibles toutes les ressources.
                <br />
                <br />
                Les trois méthodes suivantes peuvent être appelés  par le midlet même pour changer son état en cours.
                <br />
                En utilisant la méthode resumeRequest, le midlet peut initier le passage de l'état Paused à l'état Active. Cette occasion
				peut arriver, par exemple, à l'expiration d'un délai de Timeout.
                <br />
                La méthode notifyPaused permet au midlet de passer librement de l'état Active à l'état Paused.
                <br />
                Le midlet peut appeler la méthode notifyDistroyed pour annoncer qu'il a terminé le travail, sauvegardé les données nécessaires
				et rendu disponibles les ressources, et avec cela la méthode destroyApp ne sera pas appelée.
                <br />
            </div>
        </div>
        <div class="chapter">
            <h2>Conclusion</h2>
            En conclusion, je voudrais dire quelques mots en faveur de la technologie de Java ou pour être plus précisement J2ME. En la comparant avec d'autres
			technologies, comme  par exemple .NET, proposé par Microsoft, etc. Je trouve que la technologie Sun apporte plus d'avantages : elle est simple et facile
			d'utilisation (technique de programmation) à un large niveau d'utilisateurs (en tant que logiciel et documentation). Java pour les mobiles a un énorme
			potentiel surtout grâce à l'utilisation des mobiles dans la vie quotidienne, ce qui lui a déjà ouvert l'accès dans tous les domaines et sur le marché
			mondial. L'utilisation de Java(J2ME) dans les mobiles la fait de plus en plus populaire parmi les utilisateurs et les programmeurs.
            <br />
        </div>
    </body>
</html>

